I 

\ 

10/574169 

WO 2005/032094 PC17EP2004/052163 

MR Mi PCWTO 2 9 MAR ZOflf ' 



Beschreibung 

* Uberprufung der Verfugbarkeit eines Servers 

5 Die vorliegende Erfindung betrifft ein Verfahren zur Uberpru- 
fung der Verfugbarkeit eines Servers, ein Steuerungsprograinm 
und einen Client fur ein verbindungslose Dienste bereitstel- 
lendes Netz. 

10 Eine zuverlassige Oberprufung der Verfugbarkeit eines Servers 
ist insbesondere bei lose gekoppelten Client-Server-Beziehun- 
gen in paketorientierten Datennetzen von grofier Bedeutung. 
Erkennt ein Client fruhzeitig, dafi ein Server uberlastet Oder 
ausgefallen ist, so konnen noch rechtzeitig Gegenmafinahmen 

15 eingeleitet werden, beispielsweise Suche nach einem Alterna- 
tiv-Server oder Erzeugen von Warnhinweisen . Verfahren zur 0- 
berpriifung der Verfugbarkeit eines Servers, zu denen auch im 
H . 323-Standard, Stand 11/2000, Kap. 7.2.2 beschriebene Keep- 
Alive-Tests zahlen, werden angewendet, wenn keine permanente 

20 Kommunikationsbeziehung zwischen Client und Server besteht, 
ein fehlerfreies Bestehen einer solchen Beziehung jedoch 
Grundlage fur eine gewunschte Funktionalitat ist, beispiels- 
weise Internet-Telephonie. In paketorientierten Netzen dienen 
Keep-Alive-Tests beispielsweise dazu, Kommunikationsteilneh- 

25 mern einen quasi leitungsvermittelnden Charakter hinsichtlich 
gegenseitiger Erreichbarkeit zu simulieren. 

Bei gangigen Keep-Alive-Tests sendet ein Client in zyklischen 
Zeitabstanden Verf ugbarkeitsanf ragen an einen ausgewahlten 
30 Server. Wird eine Verf ugbarkeitsanf rage durch den Server in- 
nerhalb eines vorgebbaren Zeitraums beantwortet, gilt der 
Server als verfiigbar und die Kommunikationsbeziehung daher - 
als aktiv. Nachteilig an dieser Vorgehensweise ist, dafi der 
Server in der Regel durch eine Beantwortung samtlicher 

r 

35 Client-Anf ragen erheblich belastet wird. 
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Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
ein Verfahren zur Uberpriifung der Verf iigbarkeit eines Ser- 
vers, das eine Minimierung der Belastung des Servers durch an 
ihn gerichtete Verf ugbarkeitsanf ragen ermoglicht, sowie zur 
5 Durchfuhrung des Verfahrens geeignete technische Implementie- 
rungen anzugeben. 

Diese Aufgabe wird erf indungsgemafi durch ein Verfahren mit 
den in Anspfuch 1, ein Steuerungsprograram mit den in Anspruch 
10 7 und einen Client ' mit den in Anspruch 8 angegebenen Merkma- 
len gelost. Vorteilhafte Weiterbildungen der vorliegenden Er- 
findung sind in den abhangigen Anspruchen angegeben. 

Ein wesentlicher Aspekt der vorliegenden Erfindung besteht 
15 darin, daft ein Client, der auf eine an einen Server gerichte- 
te Verf ugbarkeitsanf rage eine Bestatigungsmeldung vom Server 
empfangen hat, eine Meldung iiber die Verfiigbarkeit des Ser- 
vers an weitere Clients ubermittelt . Daraufhin unterbinden 
die vorgebbaren weiteren Clients zumindest fur ein vorgebba- 
20 res Zeitintervall ein Ubermitteln einer Verf ugbarkeitsanf rage 
an den Server. Auf diese Weise kann die Belastung des Servers 
durch Verfiigbarkeitsanf ragen erheblich reduziert werden, ohne 
daft dies beispielsweise zu Lasten einer nicht mehr rechtzei- 
tigen Erkennung eines Serverausf alls oder einer Serveriiber- 
25 lastung geht. 

Die vorliegende Erfindung wird nachfolgend an einem Ausfuh- 
rungsbeispiel anhand der Zeichnung naher erlautert. Es zeigt 

30 Figur 1 ein Anwendungsumf eld der vorliegenden Erfindung mit 
zahlreichen Clients und Servern in einem paketori- 
entierten Netz mit mehreren Teilnetzen, 

Figur 2 ein Ablauf diagramm fur ein Verfahren zur Uberpru- 
35 fung der Verfiigbarkeit eines Servers, 
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Figur 3 ein Ablaufdiagramm fur ein gegenuber Figur 2 modi- 
fiziertes Verfahren, bei dem zusatzlich die Verfug- 
barkeit von Clients durch den Server uberpriift 
wird. 

5 

In Figur 1 ist ein Kommunikat ions system dargestellt, das ein 
paketorientiertes Netz mit mehreren Teilnetzen 101, 110, 120, 
130, Server 102 bis 104 und mehrere Clients 111 bis 115, 121 
bis 123, 131 bis 133 umfafit. Die Clients ill bis 115, 121 bis 
10 123, 131 bis 133 nutzen von den Servern 102 bis 104 angebote- 
ne Dienste, beispielsweise Internet-Telefonie . 

Bei den Teilnetzen 110, 120, 130 handelt es sich urn lokale 
Subnetze, dieoeweils uber einen Gatekeeper verfugen. Die Ga- 
15 tekeeper dienen vornehmlich zur Zugangskontrolle und zu Adre- 
fliibersetzungsdiensten . Diese Funktionalitat der Gatekeeper 
. kann durch Server im paketorientierten Netz ubernommen wer- 
den. 

20 Zur Nutzung von durch einen Server 102 bis 104 angebotenen 
Diensten registrieren sich die Clients 111 bis 115, 121 bis 
123, 131 bis 133 zunachst am jeweiligen Server. Dabei wird 
ein Zeitraum spezif iziert, innerhalb dessen eine Registrie- 
rung als giiltig behandelt wird. Der Ablauf eines Registrie- 

25 rungsverfahrens wird exemplarisch und ohne Beschrankung der 
Allgemeingiiltigkeit fur den Client 111 dargestellt. 

Der Client lll.verfiigt uber eine zentrale Prozessoreinheit 
(CPU) , einen Arbeitsspeicher (RAM) , eine Festplatte zur 
30 nichtf liichtigen Speicherung von Daten (HD) , einen Netzwerk- 

adapter (Tx/Rx) und eine Zeitsteuerungseinheit (Timer) . Einen 
solchen Aufbau und eine solche Funktionalitat konnen auch die 
iibrigen in Figur 1 dargestellten Clients 112 bis 115, 121 bis 
123, 131 bis 133 aufweisen. 

35 

Zur Registrierung an einem der Server 102 bis 104 ubermittelt 
der Client 111 eine Meldung mit einer Registrierungsanf orde- 
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rung RRQ an einen Server, der einen gewunschten Dienst be- 
reitstellt. In der Meldung mit der Registrierungsanf orderung 
RRQ wird ein Zeitraum spezif iziert, innerhalb dessen die Re- 
gistrierung des Clients 111 am ausgewahlten Server gultig 
5 sein soil. Aufierhalb dieses Zeitraums gilt die Registrierung 
des Clients als ungiiltig. 

Bei Verfiigbarkeit antwortet der ausgewahlte Server durch eine 
Meldung mit Registrierungsbestatigung RCF auf die Registrie- 
10 rungsanf rage. In der Meldung mit der Registrierungsbestati- 
gung RCF ebenfalls einen Gultigkeitszeitraum fur die Regist- 
rierung spezif iziert . Der vom ausgewahlten Server bestatigte 
Gultigkeitszeitraum entspricht entweder dem vom Client 111 
angegebenen Zeitraum oder ist kurzer als dieser. 

15 

Innerhalb des Gultigkeitszeitraums fur die Registrierung kann 
der Client 111 Verf ugbarkeitsanf ragen an den ausgewahlten 
Server richten. Derartige Verf ugbarkeitsanf ragen, die auch 
als Keep-Alive-Tests bezeichnet werden, werden ebenfalls in 
20 Form einer Meldung mit einer Registrierungsanf rage RRQ an den 
ausgewahlten Server ubermittelt. Eine im Rahmen eines Keep- 
Alive-Tests tibermittelte Meldung mit Registrierungsanf rage 
RRQ weist gegenuber gewohnlichen Meldungen mit Registrie- 
rungsanf rage ein gesetztes Keep-Alive-Bit ist. 

25 

Entsprechend den ITU-T-Empfehlungen H. 225.0, Stand 11/2000, 
Kapitel 7.9 ist eine verkurzte Meldung mit Registrierungsan- 
frage fur eine "Lightweight Registration" bereits ausrei- 
- chend. Dabei weist die Meldung mit Registrierungsanf rage le- 

30 diglich Angaben iiber eine Registrierungs- und Status- 

Transportadresse (RAS-Adresse) des Clients, ein gesetztes 
Keep-Alive-Bit, einen Endpunktidentif ikator fur den Client, 
einen Server- bzw. Gatekeeperidentif ikator, Berechtigungsmar- 
ken (Tokens) fur auszuf uhrende Operationen und einen Gultig- 

35 keitszeitraum fur die Registrierung. 
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Eine Meldung mit Registrierungsanf orderung RRQ, die im Rahmen 
eines Keep-Alive-Tests an den ausgewahlten Server iibermittelt 
wird, kann auch zur Verlangerung des Giiltigkeitszeitraums der 
Registrierung verwendet werden. Dies gilt jedoch nur dann, 
5 wenn 'die Meldung noch innerhalb des Giiltigkeitszeitraums der 
Registrierung vom ausgewahlten Server empfangen wird. Daher 
sollten zur Ermittlung des Endes eines Giiltigkeitszeitraums 
durch ein^n Client auch Meldungs- und Bearbeitungsverzogerun- 
gen berucksichtigt werden. Nach dem Ende des Giiltigkeitszeit- 
10 raums der Registrierung ist zur erneuten Registrierung eine 
ttbermittlung einer oben beschriebenen verkiirzten Meldung mit 
Registrierungsanf rage nicht mehr ausreichend. 

Falls die Meldung mit der Registrierungsbestatigung RCF keine 
15 Angabe iiber einen Giiltigkeitszeitraum der Registrierung auf- 
weist, wird dies dahingehend gewertet werden, dafl der ausge- 
wahlte Server keine Keep-Alive-Mechanismen fiir Verfiigbar- 
keitsanf ragen unterstiitzt . Clients sollten bei Empfang einer 
solchen Meldung ohne Angabe iiber einen Giiltigkeitszeitraum 
20 ein Versenden von Verf iigbarkeitsanf ragen arT den jeweiligen 
Server unterbinden, 

Nach Ablauf der Giiltigkeit einer Registrierung kann der aus- 
gewahlte Server eine Meldung mit einem entsprechenden Hinweis 
25 an den betroffenen Client iibermitteln, urn diesen iiber den Ab- 
lauf des Giiltigkeitszeitraums zu informieren. Dies ist insbe- 
sondere bei einem Verlust der Synchronisierung zwischen Zeit- 
steuerungseinheiten am Client einerseits und am Server ande- 
rerseits von Vorteil. 

30 

Sendet der Client 111 nach dem Ende des Giiltigkeitszeitraums 
der Registrierung eine oben beschrieben verkiirzte Meldung mit 
Registrierungsanfrage RRQ und gesetztem Keep-Alive-Bit an den 
ausgewahlten Server, so wird der Server durch eine Meldung 
35 mit Registrierungszuriickweisung RRJ reagieren. In einer sol- 
chen Meldung kann auch ein Zuriickweisungsgrund angegeben 
sein . 
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Urn eine unnotige Belastung eines Servers 102 bis 104 durch 
Verfiigbarkeitsanf ragen von Clients 111 bis 115, 121 bis 123, 
131 bis 133 zu vermeiden, informiert ein Client, der eine po- 
5 sitive Oder eine negative Antwort auf eine Verfugbarkeitsan- 
frage erhalten hat, mittels einer Multicast-Meldung MCM samt- 
liche Clients innerhalb desselben Teilnetzes 110 f 120, 130 
uber die Verfiigbarkeit des jeweiligen Servers. Durch eine Be- 
grenzung auf dasselbe Teilnetz konnen aufterdem Probleme im 
10 Hinblick auf nicht allgemein auflosbare Adressen umgangen 
werden. Insbesondere wird eine unnotige Netzbelastung durch 
nichtadressierbare Meldungen verhindert. 

Das in Figur 2 dargestellte Ablaufdiagramm dient zur weiteren 
15 Veranschaulichung eines Verfahrens zur Uberprufung der Ver- 
fiigbarkeit eines Servers in einem paketorientierten Kommuni- 
kationsnetz. Ausgangspunkt des Verfahrens ist ein Start eines 
Timers bzw. eines Zahlers einer Zeitsteuerungseinheit eines 
Clients (Schritt 201) . Durch den Timer werden Zeitpunkte 
20 festgelegt, zu denen Verfiigbarkeitsanf ragen des Clients an 
einen ausgewahlten Server iibermittelt werden sollen. 

Nach dem Start des Timers iiberwacht der Client den Empfang 
von Multicast-Meldungen MCM, aus denen sich Aussagen uber die 
25 Verfiigbarkeit eines Servers ergeben (Schritt 202) . Empfangt 
der Client eine solche Multicast-Meldung, so wird der Timer 
zuriickgesetzt (Schritt 208). Dadurch wird eine Ubermittlung 
von Verfiigbarkeitsanf ragen an den ausgewahlten Server fur ein 
vorgebbares Zeitintervall unterbunden. 

30 

Sofern keine neue Multicast-Meldung empfangen wurde, wird zu- 
satzlich iiberpriift, ob der Timer abgelaufen und damit ein 
Zeitpunkt zum Absetzen einer neuen Verfiigbarkeitsanf rage er- 
reicht ist (Schritt 203) . Wenn der Timer noch nicht abgelau- 
35 fen ist, werden weiterhin der Empfang von Multicast-Meldungen 
und der Ablauf des Timers iiberpriift. Ist der Timer abgelau- 
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fen, wird eine Verfiigbarkeitsanf rage an den ausgewahlten Ser- 
ver versendet (Schritt 204) . 

In Schritt 205 wird zumindest implizit die Verf ugbarkeit oder 
5 Nichtverf ugbarkeit des ausgewahlten Servers f estgestellt . 1st 
der ausgewahlte Server verfugbar, so antwortet dieser durch 
eine an den anfragenden Client gerichtete Bestatigungsmeldung 
auf die Verfiigbarkeitsanf rage (Schritt 206) . Nach Erhalt der 
Bestatigungsmeldung informiert der anfragende Client samtli- 

10 che weiteren Clients innerhalb desselben Teilnetzes uber die 
Verfiigbarkeit des ausgewahlten Servers mittels einer Multi- 
cast-Meldung (Schritt 207) . Daraufhin unterbinden die weite- 
ren Clients, welche die Multicast-Meldung empfangen haben, 
ihrerseits ein tibermitteln von Verf ugbarkeitsanf ragen an den 

15 ausgewahlten Server fur ein vorgegebenes Zeitintervall . 

Da bei Ausfall oder Oberlastung des ausgewahlten Servers kei- 
ne Bestatigungsmeldung uber dessen Verftigbarkeit versendet 
wird f wird iiberprtift, ob der ausgewahlte Server zumindest in 

20 der Lage ist, mit einer Nichtverfiigbarkeitsmeldung auf die 
Verfiigbarkeitsanf rage zu reagieren (Schritt 209) . Bei einer 
Oberlastung des ausgewahlten Servers ware dies beispielsweise 
noch moglich. Dagegen ist bei einem Ausfall des ausgewahlten 
Servers nicht mehr mit einem Versenden einer Nichtverfiigbar- 

25 keitsmeldung zu rechnen. Daher wird iiberpruft ob ein Zeitli- 
mit fur den Empfang einer Bestatigungsmeldung oder einer 
Nichtverfiigbarkeitsmeldung erreicht wird (Schritt 211) . Wird 
dieses Zeitlimit iiberschritten, so iibermittelt der anfragende 
Client eine Multicast-Meldung iiber die Nichtverf ugbarkeit des 

30 ausgewahlten Servers an samtliche Clients innerhalb desselben 
Teilnetzes (Schritt 210) . In entsprechender Weise wird ver- 
fahren, wenn der anfragende Client innerhalb des fur eine An- 
wort auf die Verf iigbarkeitsanfrage zulassigen Zeitlimits eine 
Nichtverf ugbarkeitsmeldung erhalt . 

35 



Das beschriebene Verfahren zur Uberpriifung der Verf ugbarkeit 
eines. Servers wird vorzugsweise durch ein Steuerungsprogramm 
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implementiert, das in einen Arbeitsspeicher eines Clients 
ladbar ist und zumindest einen Code-Abschnitt aufweist, bei 
dessen Ausfiihrung die vorangehend* beschriebenen Schritte 0- 
bermitteln der Verfugbarkeitsanf rage, Uberwachen des Empfangs 
5 einer Bestatigungsmeldung, Obermitteln einer Meldung iiber die 
Verfugbarkeit an weitere Clients, Oberwachen des Empfangs von 
Meldungen weiterer Clients und ggf . Unterbinden des Versen- 
dens von Verfugbarkeitsanf ragen ablaufen. Mittels des Steue- 
rungsprogramms wird ein Client fur ein verbindungslose Diens- 

10 te bereitstellendes Kommunikationsnetz implementiert, der ei- 
ne Einrichtung zum Ubermitteln von Verfugbarkeitsanf ragen, 
eine Einrichtung zur Oberwachung des Empfangs von Bestati- 
gungsmeldungen, eine Einrichtung zur Ubermittlung von Meldun- 
gen iiber die Verfugbarkeit von Servern an weitere Clients so- 

15 wie eine Einrichtung zur Oberwachung des Empfangs von Meldun- 
gen weiterer Clients und zum Unterbinden des Obermittelns von 
Verfugbarkeitsanf ragen aufweist. 

Die nachf olgenden Betrachtungen dienen einer Herleitung der 
20 Vorteile des beschriebenen Verfahrens zur Uberprufung der 

Verfugbarkeit eines Servers gegenuber bisher gangigen Keep- 
Alive-Tests. Entsprechend den bisher gangigen Keep-Alive- 
Tests wiirde ein Server bei n=1000 Verfugbarkeitsanf ragen sen- 
denden Clients und einer Anfragerate von a=3 Anfragen pro Mi- 
25 nute und Client sowie unter der Annahme einer zeitlichen 
Gleichverteilung derartiger Anfragen alle 

t r {a = 3, n = 1 000) = = = 20m, 

an 31000 

eine Verfugbarkeitsanf rage zu beantworten haben. 

30 Der Server ware also durchschnittlich alle 20 ms damit be-' 

schaftigt, eine Verfugbarkeitsanf rage zeitnah zu beantworten. 
Dies wiirde zu einer erheblichen Belastung des Servers durch 
Verfugbarkeitsanf ragen fuhren, was ihn in der Wahrnehmung 
seiner ihm eigentlich zugedachten Aufgaben stark einschranken 

35 wiirde . Zur Losung dieses Problems wiirde sich zunachst anbie- 
ten, die Anfragerate der Clients pro Minute stark zu reduzie- 



WO 2005/032094 



PCT/EP2004/052163 



9 

ren, was jedoch zur Folge hatte, daB die betroffenen Clients 
den Verlust der Verfugbarkeit des Server unter Umstanden un- 
zureichend spat feststellen. 

5 Fiir eine Abschatzung einer mit dem hier vorgeschlagenen Ver- 
fahren erzielbaren Vorteile wird zunachst angenommen, daiJ 
sich n Clients auf s Teilnetze verteilen. Ferner wird ange- 
nommen, dafi aus jedem dieser s Teilnetze wenigstens ein 
Client versuchen wird, die Verfugbarkeit des Servers abzufra- 

10 gen. Jeder dieser Clienst wiirde dann wiederum die ubrigen 

Clients innerhalb seines Teilnetzes mittels einer Multicast- 
Meldung liber die Serververf ugbarkeit informieren. Unter idea- 
lisierten Bedingungen wiirde die Anzahl der durch den Server 
zu bearbeitenden Verfiigbarkeitsanf ragen der Anzahl s der 

15 Teilnetze entsprechen. Zusatzlich ist noch zu berucksichti- 
gen, dafl die Multicast-Meldungen in den Teilnetzen eine Ver- 
lustrate v zwischen 0 und 100 Prozent aufweisen konnen. Damit 
ist die Anzahl v c von Clients pro Teilnetz, die von einer 
Multicast-Meldung nicht erreicht werden und somit selber eine 

20 Verfiigbarkeitsanf rage an den Server senden abhangig von der 
Verlustrate v der Multicast-Meldungen; 

•-£-•)• 

Die Gesamtzahl v c a11 aller Clients, die unter dieser Voraus- 
25 setzung tatsachlich eine Verfiigbarkeitsanf rage an den Server 
richten lafit sich damit wie folgt abschatzen: 

s 

Unter diesen Annahmen kann das Zeitintervall t r zwischen zwei 
30 an den Server gerichteten Verfiigbarkeitsanf ragen wie folgt 
berechnet werden: 

t r (a,n 9 s,v) = — . 

a • (v • n + s(\ - v)) 

Anhand eines Zahlenbeispiels wird die Belastung des Servers 
35 durch Verfiigbarkeitsanf ragen bei bisher gangigen Keep-Alive- 
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Tests der Belastung des Servers entsprechend dem hier vorge- 
schlagenen Verfahrens gegeniiber gestellt. Bei einer Anf rage- 
rate von a=3 Verfiigbarkeitsanf ragen pro Minute urid n=1000 
Clients gilt fur das Zeitintervall t r zwischen zwei Verfiig- 
barkeitsanf ragen : 

6O5 20^ 



t r (a = 3 9 n = 1000,5, v) = 



3-(v 1000 + 5(1- v)) 1000-v + 5(l-v) 



Typische Werte fur die Verlustrate v liegen deutlich unter 
100 Prozent. Mit den obigen Werten fur die Anfragerate a, die 
Anzahl n der Clients und s=10 Teilnetzen ergeben sich in Ab- 
hangigkeit von der Verlustrate v die folgenden Ef f izienzstei- 
gerungen deff in Prozent bezogen auf die gangigen Keep-Alive- 
Tests mit einem Zeitintervall t r = 20 ms zwischen zwei Ver- 
fiigbarkeitsanf ragen : 



V 


0.0 


0.1 


0.2 


0.5 


0.8 


trims] 


2000 


183 


96 


40 


25 


deff[%] 


9900 


815 


380 


100. 


25 



Bei einer Verlustrate v = 20 % betragt die mittlere Zeit t r 
zwischen zwei durch den Server zu bearbeitende Verfiigbar- 
keitsanf ragen beispielsweise ca. 96 ms. Dies entspricht einer 
Ef fizienzsteigerung d eff = 380 % im Vergleich zu bisher gangi- 
gen Keep-Alive-Tests. 

Insgesamt ist f estzustellen, daJJ bei dem hier vorgeschlagenen 
Verfahren zur Oberpriifung der Serververfiigbarkeit die Belas- 
tung des Servers durch eine Beantwortung von Verf iigbarkeits- 
anfragen deutlich sinkt, ohne da& dies zu einer signif ikanten 
Erhdhung der Zeit fiihrt, bis den Clients die Nichtverf iigbar- 
keit des Servers bekannt wird. Auflerdem sind zur Implementie- 
rung des hier vorgeschlagenen Verfahrens lediglich auf Seiten 
der Clients Anderungen notwendig. Die bisherige Vorgehenswei- 
se zur Bearbeitung von Verfiigbarkeitsanf ragen kann auf Ser- 
verseite beibehalten werden und erfordert damit keine weite- 
ren " Auf wendungen . 



WO 2005/032094 



PCT7EP2004/052163 



11 

Bei dem in Figur 3 dargestellten Verf ahren wird zusatzlich 
die Verf ugbarkeit von Clients durch einen Server uberpruft. 
Dies bedeutet, dafi ein Server auch iiber die Verf ugbarkeit von 

5 Clients informiert ist, die lediglich von einen anderen 

Client per Multicast-Meldung iiber die Verf ugbarkeit des Ser- 
vers informiert werden und nicht selber Keep-Alive-Anf ragen 
direkt an den Server richten. Zunachst startet jeder Client 
einen erster Timer (Timer 1) (Schritt 301) und uberpruft, ob 

0 eine Multicast-Sammelanf rage empfangen wurde (Schritt 302) . 
Eine Multicast-Sammelanf rage kann von einem Client als Zei- 
chen dafiir ausgesendet werden, daB dieser Client einen Sam- 
mel-Keep-Alive-Test mit einem Server durchfuhren mochte, und 
daft dieser Client dafiir die Keep-Alive-Daten anderer Clients 

5 benotigt. 

Der Zustand des ersten Timers wird fortlaufend durch den je- 
weiligen Client uberpruft (Schritt 303) . Sollte der erste Ti- 
mer noch nicht abgelaufen und keine Multicast-Sammelanf rage 

0 eingegangen sein, so wird der Empfang einer Multicast-Sammel- 
anf rage weiter uberwacht. Ist der erste Timer abgelaufen und 
keine Multicast-Sammelanf rage empfangen worden, so ubernimmt 
der jeweilige Client die Aufgabe, selber eine Multicast- 
Sammelanf rage an einen ausgewahlten Server zu richten. Dazu 

5 startet der jeweilige anfragende Client einen zweiten Timer 
(Timer 2) (Schritt 304) und ubermittelt eine Multicast- 
- Sammelanf rage an vorgebbare weitere Clients (Schritt 305) . 
Nachfolgend uberpruft der jeweilige anfragende Client, ob die 
Multicast-Sammelanf rage von den vorgebbaren weiteren Clients 

0 beantwortet wurde (Schritt 306), und ob der zweite Timer ab- 
gelaufen ist (Schritt 307) . Sollte der zweite Timer noch 
nicht abgelaufen und keine Antwort auf die Multicast- 
Sammelanf rage eingegangen sein, so wird der Empfang einer 
Antwort auf die Multicast-Sammelanf rage weiter uberwacht. 



Nach Ablauf des zweiten Timers startet der jeweilige anfra- 
gende Client einen dritten Timer (Timer 3) (Schritt 308) und 
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sendet eine Sammel-Verfugbarkeitsanf rage an den ausgewahlten 
Server (Schritt 309) . Die Sammel-Verfugbarkeitsanf rage umfafit 
Daten des jeweiligen anfragenden Clients und derjenigen vor- 
gebbaren weiteren Clients, die bis zum Ablauf des zweiten Ti- 
5 mers auf die Multicast-Sammelanf rage des jeweiligen anfragen- 
den Clients geantwortet haben. Nachfolgend uberpruft der je- 
weilige anfragende Client, ob der ausgewahlte Server Verfug- 
barkeit signalisiert hat (Schritt 310), und ob der dritte Ti- 
mer abgelaufen ist (Schritt 311) . Sollte der dritte Timer 
10 noch nicht abgelaufen und keine Antwort auf die Sammel-Ver- 
fugbarkeitsanf rage eingegangen sein, so wird der Empfang ei- 
ner Antwort auf die Sammel-Verfugbarkeitsanf rage weiter iiber- 
wacht . 

15 Hat der ausgewahlte Server seine Verf iigbarkeit dem jeweiligen 
anfragenden Client signalisiert, so ubermittelt der jeweilige 
anfragende Client eine positive Multicast-Verfiigbarkeitsmel- 
dung an die vorgebbaren weiteren Clients (Schritt 312) . Soll- 
te der ausgewahlte Server seine Nichtverfugbarkeit signali- 

20 siert Oder bis zum Ablauf des dritten Timers keine Antwort 

auf die Sammel-Verfugbarkeitsanf rage gesendet haben, so uber- 
mittelt der jeweilige anfragende Client eine negative Multi- 
cast-Verfugbarkeitsmeldung an die vorgebbaren weiteren 
Clients (Schritt 313) . 

25 

Vorgebbare weitere Clients , die entsprechend der Uberprufung 
in Schritt 302 eine Multicast-Sammelanf rage empfangen haben, 
ubermitteln ihre Keep-Alive-Daten an den jeweiligen anfragen- 
den Client (Schritt 314), deren Empfang der jeweilige anfra- 

30 gende Client entsprechend Schritt 306 uberpruft. Nachfolgend 
starten die vorgebbaren weiteren Clients einen vierten Timer 
(Timer 4) (Schritt 315) und iiberprufen, ob eine positive oder 
negative Multicast-Verfugbarkeitsmeldung des jeweiligen an- 
fragenden Clients empfangen wurde (Schritt 316), und ob der 

35 vierte Timer abgelaufen ist (Schritt 317) . Bei Empfang einer 
Multicast-Verfugbarkeitsmeldung des jeweiligen anfragenden 
Clients wird der erste Timer zuruckgesetzt (Schritt 318) , so 
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dafi die vorgebbaren weiteren Clients fur eine durch den Ab- 
lauf des ersten Timers bestimmte Zeitdauer keine Verfugbara- 
keitsanf ragen an den ausgewahlten Server richten. 

5 Solange der vierte Timer nicht abgelaufen ist, warten die 
vorgebbaren weiteren Clients auf eine Multicast-Verfiigbar- 
keitsmeldung des jeweiligen anfragenden Clients. Sollte dies 
nicht vor Ablauf des vierten Timers geschehen, ubernimmt der 
jeweilige Client nun selbst eine Rolle als Steller einer Sam- 
10 mel-Verfugbarkeitsanf rage entsprechend den Schritten 304 bis 
313, sofern der erste Timer abgelaufen ist bzw. vor seinem 
Ablauf keine weitere Multicast-Sammelanf rage eingeht. 

Die Anwendung der vorliegenden Erfindung ist nicht auf das 
15 hier beschriebene Ausfiihrungsbeispiel beschrankt. - 
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Patentanspruche 

1. Verfahren zur ttberprufung der Verf iigbarkeit eines Servers, 
bei dern 

5 - eine Verfiigbarkeitsanf rage von einem Client an einen Ser- 
ver iibermittelt wird, 
- die Verfiigbarkeitsanf rage bei Verfiigbarkeit des Servers 
durch eine vom Server an den Client iibermittelte Bestati- 
gungsmeldung beantwortet wird, 
10 dadurch gekennzeichnet, dafi der Client eine Meldung iiber die . 
Verfiigbarkeit des Servers an weitere Clients iibermittelt, die 
daraufhin jeweils ein Obermitteln einer Verf iigbarkeitsanf rage 
an den Server zumindest fur ein vorgebbares Zeitintervall un- 
terbinden. 

15 

2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, da& Daten zwischen dem Server und den 
Clients mittels verbindungsloser Vermittlungssteuerung iiber- 
mittelt werden. 

20 

3. Verfahren nach einem der Anspruche 1 oder 2, 

dadurch gekennzeichnet, dafi die Meldung iiber die Verfugbar- 
keit des Servers an die vorgebbaren weiteren Clients mittels 
Multicast iibermittelt wird. 

25 

4. Verfahren nach einem der Anspruche 1 bis 3, 

dadurch gekennzeichnet, dafl der Client nur vorgebbare weitere 
Clients innerhalb desselben Teilnetzes iiber die Verfiigbarkeit 
des Servers informiert. 

30 

5. Verfahren nach einem der Anspruche 1 bis 4, 

dadurch gekennzeichnet, daB der Client zu durch eine Zeit- 
steuerung vorgegebenen Zeitpunkten Verf iigbarkeitsanf ragen 
ausfiihrt . 
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6. Verfahren nach Anspruch 5, 

dadurch gekennzeichnet, daft jeweils ein Zahler einer Zeit- 
steuerung, die einem vorgebbaren weiteren Client zugeordnet 
ist und Verfugbarkeitsanf ragen veranlaftt, bei Empfang einer 
5 Meldung uber die Verfiigbarkeit des Servers auf einen vorgeb- 
baren Wert zuruckgesetzt wird. 

7. Steuerungsprogramm, das in einen Arbeitsspeicher eines 
Clients ladbar ist und zumindest einen Codeabschnitt auf- 

10 weist, bei dessen Ausfuhrung 

- eine Verf iigbarkeitsanf rage von dem Client' an einen Server 
ubermittelt wird, 

- ein Empfang einer die Verfugbarkeitsanf rage bei Verfugbar- . 
keit des Servers beantwortenden Bestatigungsmeldung uber- 

15 wacht wird, 

- eine Meldung uber die Verf ugbarkeit des Servers an weitere 
Clients ubermittelt wird, 

- ein Empfang einer Meldung eines vorgebbaren weiteren 
Clients uber die Verfiigbarkeit des Servers iiberwacht und 

20 ein Ubermitteln einer Verf iigbarkeitsanf rage an den Server 

zumindest fur ein vorgebbares Zeitintervall bei Empfang 
einer solchen Meldung unterbunden wird, 
wenn das Steuerungsprogramm in dem Client ablauft. 

25 8. Client fur ein verbindungslose Dienste bereitstellendes 
Kommunikationsnetz mit 

- einer Einrichtung zum Ubermitteln einer Verfugbarkeitsan- 
frage an einen Server, 

- einer Einrichtung zur Uberwachung eines Empfangs einer die 
30 Verfugbarkeitsanfrage bei Verfiigbarkeit des Servers beant- 
wortenden Bestatigungsmeldung, 

- einer Einrichtung zur Ubermittlung einer Meldung uber die 
Verfiigbarkeit des Servers an weitere Clients, 

- einer Einrichtung zur Uberwachung eines Empfangs einer 
35 Meldung eines vorgebbaren weiteren Clients uber die Ver- 
fiigbarkeit des Servers und zum Unterbinden eines Ubermit- 
telns einer Verf iigbarkeitsanf rage an den Server zumindest 
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fur ein vorgebbares Zeitintervall bei Empfahg einer sol- 
chen Meldung. 
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